home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1998 August: Tool Chest / Dev.CD Aug 98 TC.toast / Sample Code / Overview / CPlusTESample / TECommon.h < prev    next >
Encoding:
C/C++ Source or Header  |  1994-11-18  |  5.4 KB  |  145 lines  |  [TEXT/MPS ]
  1. /*------------------------------------------------------------------------------------------
  2.  
  3.     Program:    CPlusTESample 2.0
  4.     File:        TECommon.h
  5.  
  6.     by Andrew Shebanow
  7.     of Apple Macintosh Developer Technical Support
  8.  
  9.     Copyright © 1989-1990 Apple Computer, Inc.
  10.     All rights reserved.
  11.  
  12. ------------------------------------------------------------------------------------------*/
  13.  
  14. #ifndef __TECOMMON__
  15. #define __TECOMMON__
  16.  
  17. /*
  18.     These definitions are shared by Rez and C++. We use #define statements
  19.     instead of constants in this file because Rez doesn't support constants,
  20.     and since the 3.0b1 version of Rez doesn't like the C++ comments, we use
  21.     C style comments in this file as well.
  22.  */
  23.  
  24. /*    Determining an application's minimum size to request from MultiFinder depends
  25.     on many things, each of which can be unique to an application's function,
  26.     the anticipated environment, the developer's attitude of what constitutes
  27.     reasonable functionality and performance, etc. Here is a list of some things to
  28.     consider when determining the minimum size (and preferred size) for your
  29.     application. The list is pretty much in order of importance, but by no means
  30.     complete.
  31.  
  32.     1.    What is the minimum size needed to give almost 100 percent assurance
  33.         that the application won't crash because it ran out of memory? This
  34.         includes not only things that you do have direct control over such as
  35.         checking for NIL handles and pointers, but also things that some
  36.         feel are not so much under their control such as QuickDraw and the
  37.         Segment Loader.
  38.  
  39.     2.    What kind of performance can a user expect from the application when
  40.         it is running in the minimum memory configuration? Performance includes
  41.         not only speed in handling data, but also things like how many documents
  42.         can be opened, etc.
  43.  
  44.     3.    What are the typical sizes of scraps that a user might wish to work
  45.         with when lauching or switching to your application? If the amount
  46.         of memory is too small, the scrap will be purged from memory. This
  47.         can be quite frustrating to the user.
  48.  
  49.     4.    The previous items have concentrated on topics that tend to cause an
  50.         increase in the minimum size to request from MultiFinder. On the flip
  51.         side, however, should be the consideration of what environments the
  52.         application may be running in. There may be a high probability that
  53.         many users with relatively small memory configurations will want to
  54.         avail themselves of your application. Or, many users might want to use it
  55.         while several other, possibly related/complementary applications are
  56.         running. If that is the case, it would be helpful to have a fairly
  57.         small minimum size.
  58.  
  59.     What we did for TESample:
  60.  
  61.         We determined the smallest heap size that TESample could have and
  62.         still run (24K). For the preferred size we added enough space to permit:
  63.             a. a maximum size TextEdit text handle for each window (4x32000 characters)
  64.             b. a maximum usable TextEdit scrap (32000 characters)
  65.             b. a maximum scrap as a result of Copy (32000 characters)
  66.             d. a little performance cushion (see 2, above) (10K)
  67.         Result: 220K for preferred size
  68.  
  69.         For the minimum size we took the 24K and then scaled down our requirements
  70.         for a,b, and c above. We thought that providing 76 more would be "lean
  71.         and mean" for a multiwindow program (see 4, above).
  72.         Result: 96K for minimum size
  73. */
  74.  
  75. #define kPrefSize                220
  76. #define kMinSize                96
  77.  
  78. /* kMinHeap - This is the minimum result from the following
  79.      equation:
  80.  
  81.             ORD(GetApplLimit) - ORD(ApplicZone)
  82.  
  83.      for the application to run. It will insure that enough memory will
  84.      be around for reasonable-sized scraps, FKEYs, etc. to exist with the
  85.      application, and still give the application some 'breathing room'.
  86.      To derive this number, we ran under a MultiFinder partition that was
  87.      our requested minimum size, as given in the 'SIZE' resource. */
  88.  
  89. #define    kMinHeap                 (90 * 1024)
  90.  
  91. /* kMinSpace - This is the minimum result from PurgeSpace, when called
  92.      at initialization time, for the application to run. This number acts
  93.      as a double-check to insure that there really is enough memory for the
  94.      application to run, including what has been taken up already by
  95.      pre-loaded resources, the scrap, code, and other sundry memory blocks. */
  96.  
  97. #define    kMinSpace                (64 * 1024)
  98.  
  99. /* id of our STR# for error strings */
  100. #define kTEDocErrStrings     1024
  101.  
  102. /* The following are indicies into STR# resources. */
  103. #define    eNoMemory                1
  104. #define    eNoSpaceCut                2
  105. #define    eNoCut                    3
  106. #define    eNoCopy                    4
  107. #define    eExceedPaste            5
  108. #define    eNoSpacePaste            6
  109. #define    eNoWindow                7
  110. #define    eExceedChar                8
  111. #define    eNoPaste                9
  112. #define eBadFileType            10
  113.  
  114. #define    rMenuBar    1024            /* application's menu bar */
  115. #define    rAboutAlert    1024            /* about alert */
  116. #define    rDocWindow    1024            /* application's window */
  117. #define    rVScroll    1024            /* vertical scrollbar control */
  118. #define    rHScroll    1025            /* horizontal scrollbar control */
  119.  
  120. /* The following constants are used to identify menus and their items. The menu IDs
  121.    have an "m" prefix and the item numbers within each menu have an "i" prefix. */
  122. #define    mApple                    1024    /* Apple menu */
  123. #define    iAbout                    1
  124.  
  125. #define    mFile                    1025    /* File menu */
  126. #define    iNew                    1
  127. #define iOpen                    2
  128. #define    iClose                    4
  129. #define iSave                    5
  130. #define iSaveAs                    6
  131. #define iRevert                    7
  132. #define iPageSetup                9
  133. #define iPrint                    10
  134. #define    iQuit                    12
  135.  
  136. #define    mEdit                    1026    /* Edit menu */
  137. #define    iUndo                    1
  138. #define    iCut                    3
  139. #define    iCopy                    4
  140. #define    iPaste                    5
  141. #define    iClear                    6
  142. #define    iSelectAll                8
  143.  
  144. #endif
  145.